What are some real-world applications of Stacks? (Undo/Redo, Browser History)

We're building a simple text editor and want to add an 'Undo' feature. If a user types 'hello', then 'world', and hits undo, how would you use a stack to revert the last change? What exactly gets pushed onto the stack?

Imagine you're implementing a browser's back button using a stack. When the user visits Page A, then Page B, and clicks 'Back', how do you track where they came from, and what happens to Page B once they go back?

We implemented an undo/redo feature using two stacks, but users are reporting that after they undo three actions and then perform a new action, the 'Redo' button behaves unpredictably or restores stale states. What's going wrong in our stack coordination, and how do we fix it?

In our collaborative design tool, saving the entire canvas state onto an undo stack on every mouse drag is causing severe memory lag and occasional crashes. How would you refactor this stack-based undo system to be more memory-efficient without losing the ability to revert changes?

We need to design a multi-level undo/redo system for a complex web-based IDE that supports file edits, folder creations, and git operations. How would you design the command history stack to handle heterogeneous actions, and how do you enforce a strict memory limit on these stacks?

Our mobile app uses a stack-based navigation history. When users deep-link into a nested page, hit the back button, and expect to navigate through a logical hierarchy rather than their actual history, the stack model breaks down. How would you design a hybrid navigation system that reconciles historical back-clicks with hierarchical back-clicks?

We are migrating a massive legacy desktop application to a collaborative, cloud-based SaaS platform. The desktop app relied on a local, in-memory command stack for undo/redo. How do we architect a distributed undo/redo system that handles concurrent edits from multiple users while maintaining a consistent, intuitive undo stack for each individual user?

Our enterprise platform's state-management architecture is built around a centralized undo/redo stack. As teams add new micro-frontends, the global stack is becoming a bottleneck, leading to state pollution and memory leaks. How would you federate or redesign this history-tracking architecture to allow independent teams to manage their own feature history while maintaining a cohesive user experience?